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1.  INTRODUCnON 


During  iterative  development  of  software  prototypes,  different  variations  are  generally  developed  where 
each  of  the  versions  contains  a  portion  of  the  desired  capability.  Because  these  prototypes  can  be  very 
large,  tools  that  automatically  determine  the  differences  between  these  versions  and  produce  a  new  version 
exhibiting  significant  behavior  from  each  are  desirable.  This  report  describes  a  change-merging  method 
for  the  Prototype  Systan  Description  Language  (PSDL)  (Luqi,  Berzins,  and  Yeh  1988),  a  prototype  that 
is  semantics-based  arxl  guarantees  that  if  a  conflict-free  result  is  produced,  it  is  semantically  correct.  A 
fuU  definition  of  this  method  and  the  associated  tool  can  be  found  in  Dampier  (1994). 

2.  RAPID  PROTOTYPING 

Rapid  prototyping  is  an  approach  to  software  development  that  was  introduced  to  overcome  the 
following  weaknesses  of  traditional  ^preaches: 

1.  fully  developed  software  systems  that  do  not  satisfy  the  customer’s  needs,  or  are  obsolete  upon 
release 

2.  no  usability  for  accurately  evaluating  real-time  requirements  before  the  software  system  has  been 
built 

R^id  prototyping  overcomes  these  weaknesses  by  increasing  customer  interaction  during  the 
requirements  engineering  phase  of  development,  providing  executable  specifications  that  can  be  evaluated 
for  conformance  to  real-time  requirements,  and  producing  a  production  software  system  in  a  fraction  of 
the  time  required  using  traditional  methods.  Rapid  prototyping  allows  the  user  to  get  a  better 
understanding  of  requirements  early  in  the  conceptual  design  phase  of  development  It  involves  the  use 
of  software  tools  to  rapidly  create  concrete  executable  models  of  selected  aspects  of  a  proposed  system 
to  allow  the  user  to  view  the  model  and  make  comments  early.  The  prototype  is  rapidly  reworked  and 
redemonstrated  to  the  user  over  several  iterations  until  the  designer  and  the  user  have  a  precise  view  of 
what  the  system  should  do.  In  this  approach  to  rapid  prototyping,  software  systems  can  be  delivered 
incrementally  as  parts  of  the  system  become  fully  operational. 
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Change-merging  is  an  integral  part  of  the  rapid  prototyping  methodology.  During  prototype 
development,  multiple  variations  of  a  large  prototype  are  likely  to  be  developed.  This  can  happen  when 
different  development  teams  are  working  on  different  aspects  of  a  system,  or  when  different  possible 
solutions  to  a  problem  are  explored  in  different  ways.  Our  change-merging  method  will  allow  the 
combination  of  these  independently  developed  variations  to  be  done  automatically,  ensuring  that  the 
resultant  prototype  is  semantically  correct,  with  respect  to  all  of  the  input  variations.  If  the  pieces  are  not 
compatible  with  regard  to  the  semantics  of  the  prototype,  then  our  method  will  identify  the  parts  of  the 
prototype  containing  the  conflicts.  This  technology  encourages  the  designer  to  ex|:dore  different  solutions 
to  a  problem,  and  to  spread  the  development  workload  in  a  large  project  without  concern  for  the 
subsequent  integration  of  these  independent  efforts. 

The  earliest  work  on  program  merging  relied  on  combining  changes  made  to  the  text  files  containing 
the  source  code  for  the  program  (SUverberg  1992;  Tichy  1982).  These  syntax-based  methods  proved 
insufficient  to  guarantee  the  correctness  of  the  resultant  program.  Early  semantics-based  methods 
concentrated  on  higher  level  domains  (Berzins  1986)  and  simple  while  programs  (Horwitz,  Prins,  and 
Reps  1988;  Reps  and  Yang  1988;  Yang  1990).  This  work  showed  that  calculating  an  exact 
semantics-based  change-merge  is  not  possible  in  the  general  case,  but  useful  approximations  are  possible 
and  feasible. 

3.  MODEL 


PSDL  programs  are  executable  specifications  that  approximate  the  functionality  of  a  production 
software  system.  To  describe  our  method  of  change-merging  as  semantics-based,  we  must  first  describe 
the  semantics  of  the  language.  We  chose  to  model  the  behavior  of  a  prototype  by  observing  the  data  flow 
history  over  its  data  streams.  A  prototype’s  behavior  is  represented  by  sets  of  possible  histories  over  the 
streams  we  call  trace  juples.  These  trace_tuples  are  composed  of  sequences  of  data.tuples  called  traces. 
Each  trace_tuple  contains  precisely  one  trace  per  stream.  Since  PSDL  prototypes  are  nondeterministic, 
one  trace_tuple  does  not  necessarily  reflect  the  set  of  possible  histories  associated  with  a  prototype;  thus, 
we  must  consider  the  behavior  of  a  prototype  to  be  the  set  of  all  possible  trace_tuples  over  its  data 
Streams.  Since  PSDL  prototypes  are  intended  to  prototype  embedded  real-time  systems  that  may  never 
be  turned  off,  this  behavior  is  likely  to  be  of  infinite  length.  The  following  subsections  describe  the  model 
starting  with  traces  and  building  up  to  the  behavior  of  a  prototype  and  the  possibility  functions  we  use 
to  construct  the  behaviors. 
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3.1  Traces  and  Stream  Behaviors.  A  trace  is  a  sequence  {d^,  d^, ...}  of  possible  data  tuples 

written  to  a  data  stream.  Each  d^  contains  a  data  element  x,  the  name  o  of  the  operator  that  wrote  x  to 
the  stream,  the  time  tw  that  x  was  written  to  the  stream,  and  the  time  tr  that  o  last  read  its  iiqjut  streams 
before  producing  x.  A  truncated  trace  of  length  ^  is  a  sequence  containing  no  more  than  k  data  tuples. 
A  stream  behavior  is  a  set  of  possible  traces  for  a  stream. 

3.2  Trace  Tuples  and  Prototype  Behaviors.  A  trace  tuple  over  a  set  of  streams  is  a  tuple  containing 
one  trace  for  each  stream  in  the  set  This  trace  tuple  can  be  viewed  as  a  tuple  of  traces  or  a  sequence  of 
incremental  trace  tuples,  according  to  Dampier’s  (1994)  Theorem  2.  It  is,  in  fact,  this  latter  representation 
that  allows  us  to  prove  our  semantic  invariance  theorem  using  induction  over  the  length  of  the  trace  tuple. 
A  truncated  trace  mple  of  length  ifc  is  a  tuple  of  truncated  traces  of  length  no  more  than  k. 

A  prototype’s  behavior,  B,  is  defined  as  the  set  of  aU  possible  trace  tuples  over  the  streams  of  the 
prototype.  A  truncated  behavior  of  length  k,B\k,  is  the  set  of  aU  possible  trace  tuples  for  the  prototype 
truncated  at  length  k.  Constracting  the  behavior  of  a  prototype  is  done  inductively  by  using  the 
prototype’s  behavior  of  length  k  to  produce  the  behavior  of  length  +  7  as  follows: 


U 


U 


7e  B|A:  Se7>(y(5p(X)): 


U 

p(T,v)<rr 


UA 

tr<t 


This  construction  uses  the  prototype’s  truncated  behavior  of  length  k,  and  for  every  truncated  trace 
tuple  in  5  1  it,  it  produces  a  set  of  incremental  trace  tuples  that  are  appended  to  the  end  of  each  of  the  Ts. 
This  construction  produces  a  new  set  of  trace  tuples  of  length  no  mote  than  it  +  7.  Incremental  trace 
tuples  are  trace  tuples  where  each  trace  contains  2ero  or  one  data  tuple. 

3.3  Possibility  Functions.  At  the  heart  of  diisconstraction  is  the  possibility  function  for  each  operator 
in  the  prototype,  F^.  To  define  the  possibility  function  for  an  operator  o,  we  look  at  a  trace  tuple 
projection  of  the  behavior  as  a  sequence  of  input  vectors  to  o.  For  every  finite  prefix  of  a  applied 

to  o,  the  result  is  a  set  of  possible  incremental  trace  tuples  over  the  output  streams  of  o.  takes  as  input 
a  projected  trace  tuple  over  the  input  streams  of  o  and  a  read  time,  and  produces  a  set  of  possible  behavior 
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projections  over  the  output  streams  of  o.  The  read  time  is  the  time  at  which  the  last  read  operation  was 
performed  by  o  on  its  input  streams,  and  defines  which  values  were  read  by  o  to  perfoim  this  computation. 

3.3.1  Example  1;  Possibility  function  for  an  operator  p  that  implements  the  function: 

Fp  =  {({3},9),({3,4},16),({3,4,9),81),...,({3,-4,9,...,x^},x,V} 

3.3.2  Example  2:  Possibility  fimction  for  an  operator  q  that  implements  the  state  machine: 

i=l 


/V  =  {({3},3),({3,-4},-l),({3,^,9},8),...,({3,4,9,...,Xk},  ^ 

1=1 

In  Dampier  (1994),  the  Independent  Operator  Lemma  guaranteed  us  that  an  operator  has  the  same 
possibility  function  regardless  of  the  context  in  which  it  is  placed;  therefore,  it  can  be  shown  that  the 
inductive  construction  shown  above  produces  a  unique  prototype  behavior. 

3.4  Prototype  Slicing.  It  has  been  shown  that  a  portion  of  a  program’s  behavior  can  be  captured  by 
a  slice  of  the  program  with  respect  to  a  single  point  in  the  program  (Horwitz,  Prins,  and  Reps  1988;  Reps 
1989;  Weiser  1984).  We  have  developed  a  similar  method  for  isolating  a  portion  of  the  behavior  of  a 
prototype.  This  section  describes  our  method  for  taking  slices  of  PSDL  prototypes.  One  of  the 
differences  between  slicing  for  PSDL  prototypes  and  slicing  for  while  programs  is  that  PSDL  programs 
are  inherently  concurrent  and  nondeterministic.  While  programs  represent  individual  deterministic 
sequential  processes.  This  represents  a  major  contribution  of  this  woik. 

To  capture  all  of  the  prototype’s  dependencies  using  our  slicing  method,  we  must  enhance  the 
prototype’s  implementation  graph  as  follows: 

3.4.1  Definition  1:  PSDL  Prototype  Dependence  Graph:  A  Prototype  Dependence  Graph  (PDG)  for 
a  prototype  F  is  a  fully  expanded  PSDL  implementation  graph  Gp.  In  the  PDG,  Gp  -  (V,  E,  C),  the  set 
of  vertices  has  been  augmented  with  an  external  vertex,  EXT,  and  the  set  of  edges,  E,  has  been  augmented 
with  a  timer  dependency  edge  from  O;  to  o^,  for  each  pair  of  vertices  Oj  e  V,  such  that  the  control 
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with  a  timer  dependency  edge  £rom  Oj  to  Oy  for  each  pair  of  vertices  Oy  Oj  e  V,  such  that  the  control 
constraints  of  Oj  contain  timer  operations  which  affect  the  state  of  a  timer  read  by  the  control  constraints 
of  Qj. 

A  slice  of  a  PSDL  prototype  is  defined  in  terms  of  die  prototype’s  dependence  graph.  It  contains  the 
portion  of  the  prototype  that  affects  the  history  of  a  set  of  streams.  This  is  useful  in  isolating  changes 
made  to  a  base  version  of  a  prototype  in  a  modification.  If  the  slices  of  two  versions  widi  respect  to  the 
same  set  of  streams  are  different,  then  there  are  significant  changes  that  have  been  made  to  one  version 
and  not  the  odier. 

Informally,  a  slice  is  an  upstream  closure  of  a  set  of  edges  in  the  graph  fliat  includes  all  the  source 
nodes  for  the  edges  in  the  slice.  A  formal  definition  of  a  slice  follows. 

3.4.2  Definition  2:  Slice  of  a  PSDL  Prototype:  A  slice  Sfj(X)  of  a  PSDL  prototype  P  with  respect 
to  a  set  of  data  streams  X  is  the  subgraph  (V,  E,  C)  of  the  PDG  Gp  where: 

(1)  V  is  the  smallest  set  that  contains  all  vertices  eGp  that  satisfy  at  least  one  of  the  following 
conditions: 

a)  Oj  writes  to  one  of  the  data  streams  in  X 

b)  £>j  precedes  Oj  in  Gp  and  Oj  e  V 

(2)  £  is  the  smallest  set  that  contains  all  of  the  edges  eGp,  which  satisfy  at  least  one  of  the 
following  conditions: 

a)  x^e  X 

b)  Xj^  is  directed  to  some  Oj  g  V 

(3)  C  is  the  smallest  set  that  contains  all  of  the  timing  and  control  constraints  associated  with  each 
operator  in  V  and  each  data  stream  in  E. 

Figure  1  shows  a  prototype  for  a  fish  farm  control  system  called  Fishies.  Figures  2, 3,  and  4  display 
different  slices  of  Fishies. 
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H20. 


:us 


Figure  1.  Fish  farni  control  system,  fishies^  i. 


Figure  2.  Slice  of  fishiesn  with  respea  to  02,  NH3,  H20. 


3.4.3  Theorem:  Slicing  Theorem  for  PSDL  Prototypes.  Let  Sp(X)  be  the  slice  of  a  prototype  P  with 
respect  to  a  set  of  streams  X.  Then  Sp(X)  and  P  have  the  same  behavior  on  any  subset  of  the  streams  in 

W. 

The  proof  of  this  theorem  is  contained  in  (Dampier  1994).  The  significance  of  this  theorem  is  that 
a  slice  captures  a  fragment  of  the  semantic  behavior  of  a  prototype,  and  the  behavior  captured  by  that  slice 
remains  the  same  even  if  that  dice  is  made  a  part  of  a  different  prototype,  provided  that  it  is  also  a  slice 
with  respect  to  that  new  prototype.  This  property  is  the  basis  for  constructing  a  change-merging  operation 
that  can  provide  semantic  guarantees  of  correctness. 

4.  METHOD 


Our  change-merging  method  for  PSDL  prototypes  uses  prototype  slicing  to  determine  automatically 
what  parts  of  the  prototype  have  been  affected  by  a  change  and  what  parts  have  been  preserved.  Figures  5 
and  6  show  multiple  modified  versions  of  the  Fishies  prototype. 
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If  the  slice  of  a  changed  version  of  a  prototype,  with  respect  to  a  stream  present  in  both  the  base 
version  and  the  modified  version,  is  different  than  the  same  slice  of  the  base  version,  then  the  behavior 
on  that  slice  is  likely  to  be  different.  Therefore  that  change  is  significant,  and  must  be  preserved  in  the 
merged  version.  For  example,  consider  the  slice  of  Fishies^  i  with  respect  to  the  stream  Activate _Drain 
illustrated  in  Figure  7,  and  the  same  slice  of  Fishiesi^,  illustrated  in  Figure  8.  It  is  easy  to  see  a  portion 
of  the  effect  of  the  change  that  produced  Fishies^^  Fishiesi  i.  If  we  were  to  take  the  same  slice  of 
Fishies22^  we  would  discover  that  it  is  identical  to  the  slice  of  the  base  version  Fishiesi  ^.  This  illustrates 
that  this  part  of  the  Fishies  prototype  is  not  affected  by  the  change  that  produced  Fishies22-  Since  this 
change  is  significant  in  version  1.2,  it  must  be  reflected  in  the  merged  version. 

Slices  are  important  because  they  capture  all  of  the  parts  of  a  program  that  can  affect  the  behavior 
visible  m  a  set  of  data  streams.  If  two  different  programs  have  the  same  slice  for  a  set  of  streams,  they 
also  have  the  same  behavior  over  that  set  of  streams.  The  preserved  part  of  a  prototype  is  then  the  largest 
set  of  streams  that  have  the  same  single  stream  slice  in  all  three  versions,  and  the  affected  streams  of  each 
modification  are  those  that  have  a  different  single  stream  slice  in  the  modified  version  than  in  the  base 
version.  Performing  a  change-merge  using  Fishies^  as  the  base  version,  and  Fishies^i  and  FisMes^j,  as 
the  modified  versions,  we  get  the  preserved  part  as  shown  in  Figure  9  and  affected  parts  as  shown  in 
Figures  10  and  11. 
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Figure  11.  Affected  part  of  fishies^  r,. 

In  constructing  the  preserved  part,  we  consider  each  stream  individually,  taking  the  slice  of  each 
version  with  respect  to  that  stream.  If  the  slices  are  the  same,  then  that  slice  is  added  to  the  preserved 
part.  After  all  streams  have  been  checked,  the  preserved  part  is  complete. 

The  affected  parts  are  constructed  by  comparing  the  slices  of  each  stream  in  the  modified  version 
against  the  same  slice  of  the  base  version.  The  stream  is  included  in  the  affected  part  if  the  slices  are 
different. 

The  merged  version  is  formed  by  taking  the  union  of  die  preserved  part  of  all  three  versions  and  the 
affected  parts  of  the  two  modified  versions.  If  the  slice  of  the  merged  version  with  respect  to  the  streams 
affected  by  each  modification  is  the  same  as  the  corresponding  slice  of  the  modified  version,  then  semantic 
correctness  of  the  merged  version  with  respect  to  the  modifications  is  established.  The  result  of 
change-merging  Fishiesn,  Fishiesi2’  ^nd  Fishies22  is  shown  in  Figure  12. 

Our  slicing  method  has  the  advantage  of  a  clear  semantic  criterion  for  correctness,  and  the 
disadvantage  of  reporting  conflicts  whenever  two  changes  can  affect  the  same  stream,  regardless  of 
whether  there  exists  a  computation  history  in  which  the  two  changes  actually  interact  or  conflict  with  each 
other. 
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Figure  12.  Change-merged  version  of  tfie  fishies  prototype. 


5.  CHANGE-MERGE  ALGORITHM 

An  algorithm  for  our  method  is  shown  in  Figure  13.  The  sub-algorithms  for  each  of  the  individual 
parts  of  changejnerge  can  be  foimd  in  Dampier  (1994). 

The  algorithm  changejnerge  accepts  three  expanded  versions  of  a  PSDL  program  as  input.  It  then 
extracts  ah  of  the  PSDL  components  from  each  version  of  the  program.  The  atomic  components  are  held 
in  storage  to  be  included  in  the  change-merged  version  of  the  program,  if  needed.  The  composite 
component  of  each  program  is  divided  into  a  specification  part  and  an  implementation  part 

Each  of  these  parts  are  change-merged  separately  and  the  results  are  recombined  to  create  the 
change-merged  composite  component.  From  the  implementation  part  of  the  change-merged  composite 
component,  the  algorithm  can  deduce  which  of  the  atomic  components  need  to  be  included  in  the 
change-merged  program.  The  change-merged  program  is  then  remmed.  If  a  conflict  is  detected  during 
the  change-merging  process,  the  CONFLICT  variable  is  set  to  true,  and  a  flag  is  placed  into  the 
change-merged  program  at  the  location  of  the  conflict  to  aid  the  designer  in  locating  and  resolving  it 
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Algorithm  c/uinge_/n€rge(BASE,A,B:  in  psdl_program; 

CONFLICT:  out  boolean)  return  psdl_program 

begin 

1.  Extract  the  psdl_components  from  each  of  the  input  programs. 

2.  Change-merge  the  specification  parts  for  the  three  input  composite  components. 

a.  Change-merge  the  state  declarations. 

b.  Change-merge  the  exception  declarations. 

c.  Change-merge  the  maximum  execution  times. 

d.  Change-merge  the  formal  and  informal  descriptions. 

3.  Change-merge  the  implementation  parts  for  the  three  input  composite  components. 

a.  Create  the  prototype  dependency  graphs  for  each  version. 

b.  Create  the  affect^  parts  of  each  modified  version. 

c.  Create  the  preserved  part  of  the  base  in  all  three  versions. 

d.  Change-merge  the  graphs. 

e.  Change-merge  die  stream  declarations. 

f.  Change-merge  the  timer  declarations. 

g.  Change-merge  the  control  constraints. 

(1)  Change-merge  the  trigger  constraints. 

(2)  Change-merge  the  execution  guard  constraints. 

(3)  Change-merge  the  periods. 

(4)  Change-merge  the  finish_withins. 

(5)  Change-merge  the  minimiun  calling  periods. 

(6)  Change-merge  the  maximum  response  times. 

(7)  Change-merge  the  output  guard  constraints. 

(8)  Change-merge  the  exception  trigger  constraints. 

(9)  Change-merge  the  timer  operations. 

4.  Create  the  change-merged  program. 

a.  Combine  the  change-merged  specification  and  implementation. 

b.  From  the  resulting  implementation,  determine  which  of  the  atomic  components  fiom  each  of  the 
input  versions  is  to  be  included  in  the  change-merged  program. 

5.  Return  the  change-merged  program, 
end  change  jnerge: 

Figure  13.  Algorithm  change  jnerge. 


6.  SUMMARY 


We  have  provided  a  method  for  aiding  the  prototype  designer  in  independently  developing  different 
parts  of  a  software  prototype,  and  automatically  integrating  the  results  of  the  independent  efforts.  This 
will  allow  multiple  designers  to  woric  on  the  same  prototype  independently,  or  different  versions  of  the 
prototype  to  be  developed  independently,  with  the  knowledge  that  these  independent  results  can  be 
integrated  after  the  fact  with  some  guarantee  of  correctness. 
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Our  method  has  been  implemented  and  a  tool  is  available  for  use  with  die  CAPS  prototyping 
environment  to  perform  change-merging  on  real  software  prototypes.  Research  continues  to  provide  more 
useful  conflict  resolution  techniques  and  add  the  ability  to  change-merge  abstract  data  types.  Other  future 
work  wiU  concentrate  on  realizing  a  method  for  change-merging  programs  written  in  an  implementation 
language  such  as  Ada. 
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